Repository navigation
fix(modes): only the admin PIN chooses a display's mode helper - #384
Merged
Merged
Conversation
The mode helper is the input_select that /modes/ha/sync and /modes/ha/select
write to, and choosing one with { entity_id } replaces its options. Before,
any browser on the network could point a display at any input_select (house
mode, alarm mode) and rewrite or set it:
- POST /modes/ha/helper now needs the admin PIN when one is set, even on a
display that remembers it (as backups do: that flag is a device setting
any client can write). Admin asks for it before making, choosing or
disconnecting the helper.
- /modes/ha/helper answers 404 for a display that doesn't exist, instead of
creating one.
- The settings PUT/PATCH keeps the stored displayModes.ha.helper, helperId
and title, whatever the save says; the rest of displayModes.ha (report,
wake) saves as before. This also stops a stale Admin save from undoing a
helper just chosen.
- Copying another display's settings keeps this display's own helper.
The API reference lists the display-mode routes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
adamecker
pushed a commit
to adamecker/HomeGlow
that referenced
this pull request
Nov 7, 2026
…rforth#382, jherforth#384) and origin/test/all-combined into test/all-combined Upstream: Stacks/display Modes/takeovers (jherforth#378), routine complete-all (jherforth#380), mirror re-measure (jherforth#381), shared New Chore dialog (jherforth#382), admin PIN chooses the mode helper (jherforth#384). Fork side: Open-Meteo provider, precipitation probability, bonus-chore return to pool, Google Tasks no-due-date fix, dock-hide-on-dialog, HA panel test seed. Conflicts (fork's jherforth#380/jherforth#382 branches vs upstream's merged versions): took upstream's refinements (scheduleOnly, tickRemainingStepsOrThrow); app.jsx combines both (dock stays hidden while dragging is false and a dialog is open). Auto-seed now strips the HA mode-helper link from seeded settings, so a new display never inherits another display's helper (jherforth#384: only the admin PIN chooses it). The Stacks tests pre-create their devices in before(), while no device has widgets yet, so auto-seed leaves them empty.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #378: closes the open item from the review there. Any browser on the network could point a display's mode helper at any
input_selectin Home Assistant (house mode, alarm mode), then rewrite its options or set it, with no PIN.Changes
POST /api/devices/:name/modes/ha/helperneeds the admin PIN (pinin the body) when one is set. It's asked for even on a display that remembers the PIN, as backups are, becauseadminPinRememberedis a device setting any client can write. In Admin → Displays → Modes → Home Assistant, Create helper, picking an existing helper and Disconnect now ask for the PIN first (useAdminPinPrompt).displayModes.ha.helper,helperId,title) whatever the save says (keepHelperLinkinservices/displayModesHa.js).reportandwakesave as before. This also stops a stale Admin save from undoing a helper that was just chosen.docs/reference/backend-api.mdlists the display-mode routes, which weren't documented yet./sync,/selectand/reportare unchanged. They write only the helper the display already has (now chosen only with the PIN) and its ownsensor.homeglow_*_showing.Testing
displayModesHaRoutes.test.js: a save can't set or change the helper, a copy keeps the target's own helper, an unknown display gets 404 with no device made, and the PIN is needed even withadminPinRemembered: true. All four fail on main.check:i18nand the build pass.input_select.homeglow_display_modewith Automatic/Normal/Night, and the display uses it;wake;Not in this PR
displayRemembersPininroutes/haPanels.js(unlock/disarm/open from plugin frames) trustsadminPinRemembered, whichPATCH /settingsaccepts from any client. Making that flag server-owned is a separate change.🤖 Generated with Claude Code